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ABSTRACT 

Systems  engineering  is  recognized  as  a  key  to 
engineering  ships  in  an  effective  and  affordable 
manner.  A  new  challenge  is  rising  as  total  ship 
system  boundaries  are  being  re-defined  to  include 
new  warfighting  aspects  in  the  design  process. 
This  introduces  not  only  an  expansion  to  new 
subsystems  as  part  of  the  process,  but  adds  new 
complexity  to  the  designer’s  consideration.  This 
paper  discusses  the  challenges  associated  with 
engineering  the  total  ship  as  part  of  the  joint 
warfare  system  from  two  important  aspects,  the 
impact  of  differing  design  team  perspectives  and 
inherent  system  complexity. 

INTRODUCTION 

Systems  engineering  is  recognized  as  a  key  to 
engineering  ships  in  an  effective  and  affordable 
manner  (Leopold,  Svendsen,  and  Kloehn  1982), 
(Rains  1990),  (Reed  1981),  (Tibbetts,  Keane,  and 
Riggins  1988).  Naval  engineering  has  long  been 
the  title  associated  with  the  system  design  and 
engineering  of  naval  warships.  “Total  ship 
system  engineering”  (TSSE)  has  been  recently 
defined  in  an  attempt  to  describe  this  systems 
view,  and  provide  a  framework  for  ship  designer's 
to  follow.  Implementation  of  TSSE  has  always 
been  complicated  due  to  the  need  to  integrate  the 
working  of  engineering  teams  with  differing 
warfare  perspectives,  principally  ‘naval 
architecture’  and  ‘combat  systems’.  A  new 
challenge  is  arising  as  total  ship  system 
boundaries  are  being  redefined  to  include  new 
integrated  and  joint  warfighting  aspects  in  the 
design  process.  TSSE  concentrates  on  the  ship  as 
the  object  of  design,  but  this  must  be  done  in  the 
context  of  all  the  interconnected  system  aspects 
external  to  the  ship  simultaneously.  This 
introduces  not  only  an  expansion  to  new 
subsystems  as  part  of  the  process,  but  adds  new 
complexity  to  the  designer’s  consideration.  This 
paper  discusses  the  challenges  associated  with 
engineering  the  total  ship  as  part  of  the  joint 
warfare  system  from  two  important  aspects,  the 


impact  of  differing  design  team  perspectives  and 
inherent  system  complexity. 

THE  SHIP  AS  PART  OF  A 
COMPLEX  SYSTEM 

A  warship  is  just  one  part  a  total  system  that  fits 
in  a  system  and  associated  subsystems,  or  system- 
of-systems,  context  as  part  of  the  battlegroup, 
expanding  to  include  interconnectivity  with  a 
joint  force  structure  (Hockberger  1996).  The 
complexity  associated  with  the  engineering  of 
warship  concepts  is  observed  when  considering 
the  multiplicity  of  functions  desired  and  the  large 
number  of  physical  subsystems  and  parts.  The 
fact  that  the  system  must  be  considered  becomes 
obvious  if  one  considers  that  inserting  a  single 
highly  advanced  warship  as  a  node  into  an 
existing  battlegroup,  that  interoperability  cannot 
be  obtained  since  the  equipment  processing  and 
interconnective  protocols  are  incompatible.  The 
complexity  shows  up  in  the  behavior  of  the 
networked  ship  system,  however  the  behavior  of 
interest  emerges  only  after  the  system  is  actually 
integrated  and  operated.  Such  a  large-scale 
complex  system  is  difficult  to  analyze  as  a  whole. 

A  useful  tool  to  organize  large-scale  systems  into 
manageable  subsystems  is  decomposition.  Using 
decomposition,  a  system  can  be  broken  down  into 
any  number  of  logical  subsystems  arranged  in  a 
hierarchy  that  defines  the  interconnections  among 
file  subsystems.  The  hierarchy  maintains  the 
structure  of  the  system  through  subsystem 
interconnections.  The  hierarchy  can  be  useful  in 
studying  the  analysis  of  a  large  system,  or  can  be 
used  to  study  the  working  organization  of  the 
engineering  teams  performing  a  ship  design.  Any 
hierarchy  created  by  decomposing  a  system 
depends  on  the  perspective  taken  by  the  viewer, 
and  subsequently  any  number  of  decomposed 
hierarchies  can  be  defined  for  the  same  set  of 
systems.  When  viewing  a  system,  the  designer 
defines  a  desired  perspective,  focussing  on  an 
aspect,  then  decomposes  that  aspect  into 
subsystems  in  order  to  create  a  logical  structure 
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with  bounded  subsystems  that  can  be  more  easily 
analyzed  and  engineered.  A  naval  warship,  for 
example,  has  hull,  mechanical,  and  electrical 
(HM&E)  systems  for  mobility,  survivability,  and 
habitability,  a  combat  system  to  engage  the 
enemy,  and  is  an  element  of  the  warfare  system. 
For  each  of  these  -  HM&E,  combat,  warfare  -  the 
boundaries  and  interacting  elements  are  different. 
They  are,  in  fact,  three  distinct  subsystems,  all 
part  of  a  decomposed  system  hierarchy  with  the 
HM&E  and  combat  that  can  be  defined  as 
sublevel  systems  as  shown  in  Figure  1 .  Currently, 
subsystems  are  commonly  created  for  assignment 
to  designers,  with  the  system  integration 
occurring  only  after  each  sublevel  domain  has 
done  much  design  trade-off  exclusive  of 
considerations  of  the  other,  and  without 
measuring  of  system  effectiveness. 


Figure  1.  One  Possible  Warfare  System 
Decomposition  Hierarchy 


THE  WARFARE  SYSTEM 

TSSE,  and  the  expansion  of  the  traditional  naval 
architectural  focus  on  the  ship  hull,  mechanical, 
and  electrical  systems,  evolved  beginning  about 
the  time  of  the  first  naval  tactical  data  system 
(NTDS)  installation  on  USS  California  and  the 
AEGIS  system  design  for  the  USS  Ticonderoga  in 
the  1970’s.  Combat  system  engineers  have  dealt 
with  this  aspect  regularly  since  then,  with  new 
requirements  driving  the  need  for  innovative 
technologies,  and  technologies  continuing  to 
change  and  improve  rapidly  according  to  Moore's 
Law.  The  basis  on  which  mission  effectiveness  is 
measured  is  now  much  more  concerned  with  the 
ethereal  interconnections  of  data  nodes  and 
electromagnetic  interconnections  than  with  direct 
physical  contact  interactions  arising  from  the  ship 
interface  with  the  natural  environment.  The 
interconnective  electromagnetic  properties  are 


just  as  real  and  physical,  but  their  manifestations 
as  system  performers  are  harder  to  determine  in 
the  early  stages  of  concept  design.  For  example, 
the  effectiveness  of  a  network  of  nodes  cannot  be 
determined  a  priori,  since  the  network  behavior  is 
an  emergent  system  property. 

Consider  a  naval  warfare  system,  such  as  the 
battlegroup  shown  in  Figure  2.  Elements  of  a 
battlegroup  include  surface  ships,  submarines, 
aircraft,  satellites,  and  many  other  joint  assets.  A 
battlegroup  system  when  deployed  at  sea  may 
cover  a  large  area  and  some  elements  may  be 
separated  by  many  miles,  and  most  may  be  over 
the  horizon  from  any  single  ship  perspective.  The 
force  appears  as  a  group  of  independent  physical 
objects.  What  are  not  shown  are  the 
commimication  links  among  the  different 
battlegroup  elements.  These  links  provide  tactical 
data  and  force  orders  so  that  there  is  connectivity 
among  the  different  elements,  or  nodes,  of  the 
force.  These  communication  links  allow  the 
individual  nodes  of  the  battlegroup  to  act  in 
concert  with  one  another.  For  many  years  these 
communications  were  limited  to  information 
passed  from  person-to-person,  but  now  include 
data  automatically  passed  from  computer-to- 
computer. 


Figure  2.  Battlegroup  Steaming  in  Formation 


The  physical  equipment  elements  that  facilitate 
battlegroup  connectivity  are  the  transmitters  and 
receivers  that  support  everything  from  voice  links 
to  automatic  digital  data  links.  There  is  also 
equipment  for  data  processing,  storage,  and 
display.  These  elements  are  integrated  on  their 
respective  ships  and  provide  connectivity  to  other 
ships.  In  this  way  the  physically  independent 
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ships  and  other  elements  of  the  battlegroup  are 
nodes  that  are  integrated  through  networks  to 
form  a  warfare  system.  Unlike  the  ship  system 
elements,  the  warfare  system  elements  are  not 
permanently  integrated  during  the  design  and 
development  process.  Shared  data  is  derived 
from  the  data  collected  by  individual  force 
elements  and  from  sources  outside  the 
battlegroup.  The  process  of  integrating  the 
battlegroup  to  form  a  warfare  system  occurs  as 
the  force  deploys,  and  exists  while  it  is  deployed, 
but  vanishes  when  the  deployment  ends.  This 
transitory  nature  of  warfare  systems  offers  a 
challenge  to  design.  The  challenge  is  not  to 
verify  that  connectivity  exists  in  the  deployed 
force,  but  rather,  the  challenge  is  to  verify  the 
capability  to  maintain  connectivity  even  before 
the  force  is  designed. 

Naval  architects  are  just  now  beginning  to  face 
similar  challenges  within  the  ship  system  itself. 
For  example,  manning  reduction  is  being 
ag^essively  pursued,  and  as  personnel  are 
removed,  the  functions  traditionally  performed  by 
them  must  be  automated.  This  requires 
incorporating  automated  machines  as  an  integral 
part  of  the  design,  with  due  consideration  of  the 
ship  function  as  a  part  of  the  warfare  system.  The 
naval  architect  maps  functions  to  the  physical 
systems,  requiring  allocation  to  either  automated 
machines  or  persoimel.  To  accomplish 
automation,  computer  networks  integrate  the 
system  elements  by  automatically  collecting  and 
processing  data  so  when  functionally  integrated, 
the  HM&E  and  combat  system  is  a  computer 
automated  man-made  machine  with  self-operating 
characteristics.  These  self-operating 
characteristics  are  difficult  for  the  naval  architect 
to  model  without  considering  the  entire  system  in 
a  dynamic  sense  during  the  design  process. 

WARFARE  SYSTEM  BEHAVIOR 

The  behavior  of  networked  warfare  systems  can 
be  readily  defined  in  the  context  of  what  has 
become  known  as  complex  adaptive  systems 
(CAS)  (Holland  1995).  For  example,  consider 
any  large  city. 


“Buyers,  sellers,  administrations, 
streets,  bridges,  and  buildings 
make  up  the  physical  parts  of  the 
city.  These  are  not  static  parts, 
they  are  always  changing,  so  that 
a  city's  coherence  is  somehow 
imposed  on  a  perpetual  flux  of 
people  and  structures.  No  single 
constituent  remains  in  place,  but 
the  city  persists.  What  enables 
cities  to  retain  their  coherence 
despite  continual  disruptions  and 
a  lack  of  central  planning?  ’’ 

Similarly,  a  networked  battlegroup's  coherence,  or 
persistence,  depends  on  extensive  interactions,  the 
aggregation  of  diverse  elements,  and  adaptation  to 
environmental  change.  In  broad  terms  that  relate 
to  the  fields  of  economics,  biology,  and  many 
other  areas,  CAS  are,  without  excqjtion,  made  up 
of  large  numbers  of  active  elements  that  are 
diverse  in  both  form  and  capability. 

With  reference  to  CAS,  the  coherence  of  a 
warfare  system  is  best  viewed  as  a  set  of 
interacting  agents,  or  nodes,  with  interaction 
described  in  terms  of  rules  or  protocols.  As  nodes 
perform  together,  they  define  a  behavior  not 
based  just  on  their  individual  characteristics,  but 
from  the  aggregation  of  their  combined 
interaction.  Aggregation  has  been  identified  as  a 
basic  characteristic  of  all  CAS,  and  the  emergent 
phenomena  that  result  is  the  most  applicable 
aspect  for  understanding  the  warfare  system. 
Emergence  defines  the  complex  large-scale 
behaviors  resulting  from  the  aggregate 
interactions  of  subsystem  nodes.  Emergent 
behavior  manifests  itself  in  complex  temporal 
patterns.  This  emergent  behavior  is  the  product 
of  progressive  adaptation  to  changing  inputs  and 
outputs  due  to  the  flow  of  information  through  the 
warfare  system.  Flows  over  a  network  of  nodes 
and  connectors  can  be  defined  in  terms  of  triads, 
(node,  connector,  resource)  that  for  a  warfare 
system  consist  of  (computer  systems, 
electromagnetic  links,  combat  information).  In 
general  terms,  the  nodes  are  processors  and  the 
connectors  designate  the  possible  interactions.  In 
CAS  the  flows  through  these  networks  vary  over 
time,  creating  a  temporally  dynamic  system. 
Nodes  and  connections  can  appear  and  disappear 
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as  the  computer  systems  adapt  or  fail  to  adapt,  yet 
the  battlegroup  must  remain  as  a  coherent  entity. 
Thus  neither  the  flows  nor  the  networks  are  fixed 
in  time.  The  warfare  system  can  now  be  defined 
not  just  by  the  physical  elements,  but  by  the 
coherence  of  the  overall  fimction,  and  the 
emergent  behavior  manifested  by  patterns  that 
reflect  changing  adaptations  as  time  elapses  and 
information  accumulates. 

When  the  warfare  system  is  viewed  this  way,  the 
main  engineering  goal  becomes  one  of  defining 
system  coherence  rather  than  just  the  elements  of 
the  battlegroup,  and  designing  to  ensure  required 
coherent  functions  are  achieved.  This  becomes 
challenging  in  the  face  of  the  fact  that  the  major 
factor  in  determining  the  effectiveness  is  based  on 
emergent  behavior  that  cannot  be  defined  until  the 
system  is  built  and  deployed,  or  until  a  theoretical 
framework  for  determining  the  emergent  behavior 
can  be  put  forward. 

It  is  difficult  enough  that  we  must  now  deal  with 
the  design  and  engineering  of  a  CAS,  but  we  must 
also  deal  with  a  diverse  set  of  engineers  that 
define  their  own  world  in  which  to  accomplish 
their  goal  of  designing  this  system.  In  order  to 
provide  some  way  to  mitigate  the  challenges 
associated  with  engineering  the  warfare  system, 
the  overall  ship  design  process  characteristics  are 
presented.  The  two  views  of  the  design  process 
are  presented,  followed  by  a  comparison  of  the 
two  views  in  an  attempt  to  create  a  framework 
that  can  be  used  to  define  a  single,  common 
method  with  which  to  view  warfare  system 
engineering. 

WARFARE  SYSTEM  DESIGN 
PROCESS  OVERVIEW 

In  basic  terms,  design  can  be  defined  as  a  process 
to  determine  form  based  on  function.  Concepts 
are  engineered  as  physical  objects  that  map 
function  to  form.  For  most  familiar  objects,  this 
is  a  fairly  straightforward  process;  one  that  all 
engineers  are  familiar  with  inside  their  own 
specialty,  such  as  mechanical  or  electrical 
engineering,  for  instance.  Warship  design  teams, 
however,  must  not  only  address  the  factors 
common  to  all  seagoing  vessels  such  as  hull  form. 


propulsion,  and  maneuverability,  but  also  the 
choice  and  placement  of  command,  control, 
communications,  computers,  intelligence, 
surveillance,  and  recoimaissance  (rtSR)  and 
weapons  systems,  including  their  sensors, 
processors,  and  actuators.  The  ship  system  is 
generally  characterized  using  two  domains  in 
which  the  design  is  accomplished.  One  domain  is 
associated  with  the  subsystem  that  is  designed  to 
operate  on  the  water,  broadly  labeled  here  as 
naval  architecture.  This  domain  includes  the  ship 
and  HM&E  systems.  The  other  domain  is  the 
subsystem  that  is  designed  to  carry  out  the  combat 
capability,  broadly  labeled  here  as  combat 
systems  engineering.  This  domain  includes  the 
weapons  and  ^SR  systems.  These  two  sub- 
domains  in  the  combat  systems  engineering 
domain  use  distinctly  different  engineers, 
however,  their  design  process  thinking  is  similar, 
so  they  are  grouped  together.  Although  the  naval 
architecture  and  combat  system  domains  are  not 
disjoint,  they  are  often  treated  as  such  in  practice, 
with  engineers  and  design  teams  working  in  their 
own  domain.  Each  domain  can  be  successfully 
considered  independently,  as  long  as  the 
interconnection  dependence  between  them,  and 
any  relationships  to  the  other  subsystems  in  the 
hierarchy,  is  taken  into  account. 

THE  SHIP  SYSTEM 

Naval  architecture  and  marine  engineering  are  the 
traditional  disciplines  associated  with  defining  the 
design  of  ship  hull,  mechanical,  and  electrical 
systems.  Recently,  naval  engineering  and  TSSE 
have  taken  the  place  of  naval  architecture  to 
broaden  the  engineering  toward  the  naval  warship 
system.  These  engineering  disciplines  include  the 
consideration  of  combat  systems  as  part  of  the 
design  process,  though  not  necessarily  to  the  same 
level  that  combat  system  engineers  would  in  their 
designs.  For  purposes  of  this  discussion, 
however,  the  identifier  ‘naval  architecture’  will  be 
used  to  represent  the  TSSE  ship  designer’s  point 
of  view.  For  the  naval  architect,  combat  systems 
are  treated  as  fixed  inputs  to  the  ship  design,  so 
that  interfacing  physical  parameters  such  as 
weight,  volume,  centers  of  gravity,  arcs  of  fire, 
electromagnetic  radiation  interference,  and  sensor 
coverage  ensure  a  properly  designed  physical 
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total  ship  system.  The  naval  architect’s  view  of 
ship  system  design  consists  of  a  process  that  is 
traditionally  viewed  as  a  highly  coupled 
eollection  of  interrelated  physical  attributes.  For 
instance,  the  selection  of  a  power  level  for  ship 
propulsion  requires  knowledge  of  the  resistance 
of  the  ship  hull.  The  ship  hull  geometry  cannot 
be  fully  determined  until  the  entire  weight  and 
volume  required  to  be  carried,  including  that  of 
the  propulsion  system,  is  known.  The  same  is 
true  of  many  other  physical  aspects  of  the  design 
as  they  directly  impact  other  physical  aspects. 
Therefore,  once  one  aspect  is  fully  developed,  it 
often  requires  modification  based  on  its 
relationship  with  other  functionally  unrelated 
parameters.  This  philosophy  is  extensively 
discussed  in  the  literature,  as  an  iterative  process 
commonly  referred  to  as  “The  Design  Spiral” 
(Evans  1959).  Since  its  introduction,  several 
variations  have  been  developed.  The  spiral  itself 
is  consistent  between  all  variations,  but  the 
“spokes”  defining  each  aspect  of  the  design 
differs  somewhat  from  version  to  version.  Figure 
3. 


Figure  3.  MIT  Design  Spiral 


The  spiral’s  spokes  represent  the  set  of  all  major 
areas  that  must  be  addressed  throughout  the 
design  process  to  completely  define  the  ship.  The 
spiral  itself  depicts  the  current  practice  of 
independently  developing  each  required 
parameter  in  a  sequential  manner,  evaluating  the 
relationship  between  design  attributes,  iterating  to 
resolve  conflicts,  and  repeating  the 
evaluation/iteration  process  until  all  conflicts  are 


resolved.  Thus,  following  each  successive 
iteration,  the  design  progresses  closer  and  closer 
to  the  spiral's  center  imtil  convergence  is  attained 
at  a  constant  radius  from  the  center. 

Methods  to  expand  the  usefulness  of  the  design 
spiral  have  been  developed.  The  factor  of  time 
was  added  to  the  model  (Andrews  1981).  The 
essential  concept  remains  the  same,  but  the  visual 
representation  moved  into  three  dimensions,  with 
the  added  third  dimension  representing  time. 
Figure  4  is  the  resulting  cone  shaped  model.  The 
design  progresses  through  time  by  “cork¬ 
screwing”  down  the  cone  following  a  helical  path. 
A  cross  section  of  the  cone,  essentially  a  spiral, 
represents  a  snapshot  of  the  design  process  at  a 
given  instance.  Design  convergence  is  achieved 
at  the  cone’s  apex. 


Figure  4.  Enhanced  Design  Spiral  (Andrews  1981) 


Limitations  of  the  spiral  method  description  have 
been  recognized,  specifically,  the  inadequate 
addressing  of  concurrent  engineering  practices 
and  life  cycle  concerns.  One  proposed  solution  to 
remedy  these  shortfalls  is  Decision-Based  Design 
for  the  design  of  ships  (Mistree,  et  al.  1990).  This 
method  divides  the  design  process  into 
subproblems  that  are  solved  in  hierarchical  order. 
The  primary  challenge  to  implementing  this 
method  is  to  define  the  hierarchical 
decomposition  of  the  design  process  subproblems. 
No  rigorous  and  generalizable  methods  are 
defined  as  part  of  this  implementation. 

More  recent  discussions  view  the  ship  design 
process  as  a  combination  of  non-hierarchical  and 
hierarchical  subproblems  interacting  in  ways  that 
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are  difficult  to  define  and  therefore  nearly 
impossible  to  implement  in  practice  (Brown 
1993).  The  concept  of  decomposing  the  process 
seems  the  best  way  to  accomplish  ship  design,  but 
there  is  no  currently  defined  method  to  do  this, 
with  coordination  of  the  decomposed  process 
becoming  the  major  challenge. 

With  due  consideration  of  the  attempts  to  model 
and  implement  newer  design  methods,  naval 
architecture  remains  a  well  developed  discipline 
that  uses  theories  principally  derived  from 
physical  laws  of  fluid  mechanics  and  strength  of 
materials  to  design  most  aspects  of  the  ship,  such 
as  the  ship  hull  structure,  et  cetera  (Gillmer  and 
Johnson  1982).  As  an  illustration,  consider  ship 
stability.  The  ship  can  be  successfully  modeled 
as  a  self-propelled  semi-rigid  body  that  is 
supported  by  a  fluid  and  moves  with  six  degrees 
of  freedom.  To  be  stable  it  will  have  an  upright 
afloat  position  that  exhibits  stable  equilibrium.  In 
other  words,  it  returns  to  its  original  position 
when  heeled  by  an  external  inclining  force  that  is 
applied  and  subsequently  removed.  Conversely,  a 
ship  in  unstable  equilibrium  does  not  return  to  its 
original  position  resulting  in  capsizing. 

Stability  of  the  ship  is  determined  by  applying 
basic  physical  laws.  For  example;  Newton’s  laws 
will  determine  the  center  of  gravity  (G); 
Archimedes'  principle  will  determine  the 
buoyancy;  and  the  physieal  hull  form  geometry 
will  determine  both  the  center  of  buoyancy  (B) 
and  the  metacenter  (M),  the  theoretical  point 
about  which  the  ship  pivots  when  exposed  to  an 
external  inclining  force.  Stability  requires  the 
metacenter  to  be  above  the  center  of  gravity  as 
shown  in  Figure  5.  The  location  of  the  center  of 
gravity  will  not  change  with  ship  motion,  but  the 
center  of  buoyancy  will  change  as  the  displaced 
volume  changes.  The  coupling  between  the  force 
of  gravity  and  the  buoyant  force  will  maintain 
stable  equilibrium  of  the  ship  as  it  imdergoes 
longitudinal  and  transverse  motion  relative  to  a 
horizontal  plane.  Not  all  naval  engineering 
aspects  can  be  so  easily  performed,  as  the 
emergent  properties  of  seakeeping  and 
survivability  should  illustrate. 


Figure  5.  Transverse  Metacentric  Parameters 

THE  COMBAT  SYSTEM 

The  combat  system  engineer’s  view  is  based  on 
systems,  and  is  tempered  by  the  need  to  consider 
both  a  hard  physical  object  and  the  more  ethereal 
aspects  of  the  design.  In  the  combat  system 
engineer’s  view,  a  system  can  be  defined  as  a 
bounded  set  of  interacting  elements  as  shown  in 
Figure  6.  The  system  elements  are  physical 
objects,  such  as  transmitters,  receivers,  and 
sensors,  and  they  constitute  a  physical  view  of  the 
system.  For  the  elements  to  interact  they  will 
have  some  form  of  connection  which  can  vary 
from  direct  physical  contact  to  electromagnetic 
links.  The  boundary  separates  the  system  from 
the  rest  of  the  world,  and  it  is  at  the  boundary 
where  inputs  are  given  to  the  system  and  outputs 
are  received  from  the  system.  The  system  has  at 
least  one  input  and  at  least  one  output,  and  the 
system  function  is  defined  by  the  relationship  of 
the  input  to  the  output.  For  instance,  if  the  system 
is  a  radar  used  to  detect  and  track  targets  then  the 
input  would  be  detection  and  the  output  would  be 
track.  In  general,  a  functional  description  of  a 
system  requires  describing  how  each  element 
contributes  to  converting  input  to  output  and  how 
the  different  elements  interact  in  accomplishing 
the  conversion.  A  given  system  may  be  required 
to  perform  a  set  of  functions,  that  is,  there  may  be 
different  kinds  of  inputs  and  multiple  outputs. 
Designing  and  building  a  system  requires 
integrating  its  elements  in  such  a  way  that  the 
internal  behavior  of  each  element,  when  coupled 
through  the  collective  interaction  of  all  elements, 
results  in  satisfying  all  the  required  system 
functions.  The  elements  of  multifunction  systems 
will  be  time  shared  by  the  different  functions. 
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Multifunction  systems  require  complicated  timing 
and  control  across  all  elements.  Timing  and 
control  is  not  a  required  system  function  that 
converts  input  to  output,  rather  it  is  a  function  that 
is  required  to  integrate  the  system  elements. 


Figure  6.  System  as  viewed  by  Combat  System 
Engineers 


Physical  integration  is  the  joining  of  elements  to 
form  a  physically  connected  structure,  such  as  a 
highway  bridge  or  the  hull  of  a  ship.  Functional 
integration  involves  joining  elements  to  form  a 
functionally  connected  structure,  such  as  a  group 
of  ships  acting  as  a  battlegroup  system  by  means 
of  data  exchanged  over  electromagnetic  links. 

The  elements  of  functionally  integrated  structures 
interact  by  means  of  input  and  output  signals, 
whereas  the  elements  of  physically  integrated 
structures  interact  by  direct  contact.  Warships  are 
elements,  though  systems  in  themselves,  that  are 
integrated  both  physically  and  functionally.  The 
evaluation  of  these  two  aspects  for  design 
requirement  adequacy  is  quite  different  depending 
on  whether  the  functional  or  physical 
characteristics  are  being  verified.  Traditional  test 
and  evaluation  methods  are  readily  applied  to  the 
physical  characteristics,  but  are  less  adaptable  for 
establishing  functional  characteristics.  The 
combat  system  engineering  process  for  design  and 
integration  may  be  summarized  in  general  as 
follows: 

•  System  functions,  i.e.,  input-output  pairs, 
defined 

•  Physical  elements  identified 


•  System  functions  subdivided  and  allocated  to 
various  physical  elements 

•  Physical  elements  designed,  built,  integrated, 
and  tested 

The  process  is  iterative,  all  the  steps  are  repeated 
imtil  a  design  solution  can  be  found  such  that  all 
the  elements  interact  properly  to  transform  input 
to  the  desired  output.  One  reason  the  process  is 
iterative  is  that  integration  requires  interfaces 
between  the  individual  elements.  Each  interface 
will  need  an  output  from  one  element  to  be  input 
to  another.  Each  output-input,  or  input-output, 
requires  an  element-to-element  function  as  a 
consequence  of  system  integration.  The  existence 
of  these  integration  functions  -  including  timing 
and  control  of  all  elements-means  that 
decomposing  system  functions  into  sub-functions 
to  be  allocated  to  elements  cannot  be  arbitrary  and 
is  frequently  non-linear.  The  required  functions 
may  always  be  mathematically  decomposed  into 
sub-functions  that  add  by  linear  superposition. 
When  these  sub-functions  are  allocated  to 
elements  they  will  combine  with  the  integration 
functions  and  the  sum  will  represent  the  actual 
system. 

A  warship  is  outfitted  with  a  combat  system,  that 
is,  sensors  and  weapons  capable  of  detecting  and 
engaging  air,  surface,  and  subsurface  targets.  An 
example  of  a  combat  system  is  shown  in  Figure  7. 
Elements  of  the  combat  system  -  sensors, 
weapons,  and  man-machine  interfaces  -  are 
integrated  functionally  with  each  other.  They  are 
also  integrated  physically  with  HM&E  as  part  of 
the  ship  structure.  Physically,  the  combat  system 
is  described  by  mathematics  based  on  physical 
laws  similar  to  the  way  HM&E  is  described. 
Functionally,  the  combat  system  is  integrated 
independent  of  HM&E,  so  that  functionally  it  is 
not  part  of  the  ship  structure. 

Functional  integration  is  matured  by  a  heuristic 
approach  that  includes  test  and  evaluation  as  an 
integral  part  of  the  process.  The  functional  design 
can  be  done  independent  of  the  physical  ship 
structure.  However,  the  physical  and  electrical 
design  and  integration  is  done  as  part  of  the 
HM&E.  The  combat  system  is  an  integral  part  of 
the  space,  weight,  and  power  consumption  of  the 
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Figure?.  Combat  System 


ship,  but  it  also  has  specified  functional 
characteristics  that  are  independent  of  that 
structure. 

GENERAL  OBSERVATIONS 

The  engineering  process  for  warfare  systems, 
composed  of  ship  HM&E  and  combat  systems, 
differ,  but  must  be  considered  in  an  integrated 
fashion.  The  characteristics  are  not  the  same 
within  each  domain,  so  each  has  evolved  its  own 
approach  based  on  the  nature  of  the  problems. 

TTie  traditional  approach  to  naval  architecture  in 
engineering  a  total  ship  is  based  in  large  part  on 
the  physics  associated  with  objects  based  on 
traditional  theoretical  knowledge.  The  approach 
for  the  combat  system,  and  likewise  the  warfare 
system,  is  to  rely  on  a  more  heuristic  approach, 
mainly  due  to  the  need  to  design  for  emergent 
behavior  that  is  currently  not  founded  on  a  well 
defined  theoretical  basis.  The  differences  are 
subtle,  but  they  have  an  impact  on  the  ability  to 
engineer  the  total  ship. 

Each  domain  defines  and  uses  the  term  “function” 
differently.  To  the  naval  architect,  a  function  is  a 
use  to  which  a  form  is  put.  To  the  combat  system 
engineer,  a  function  is  a  term  used  to  define  the 
use  of  an  element,  module,  or  subsystem,  more  in 
terms  of  a  transform  of  input  to  output. 

Functional  integration  (combat  system  engineer 
usage)  is  driven  by  computer  automation  that  has 
continued  to  grow  in  scope  of  application  and 


now  includes  automating  the  battlegroup  to  form 
a  warfare  system.  This  difference  causes  more 
than  just  communication  problems  between  the 
domain  engineers. 

Both  domains  use  an  iterative  process.  Iteration 
necessarily  dictates  the  modification  of  each 
parameter  conflicting  with  one  or  more  other 
parameters  until  agreement  in  all  aspects  is 
reached.  Therefore,  the  final  synthesized  design 
is  a  variation  of  the  designer’s  vision  often  arrived 
upon  using  trial-and-error  methods.  This  process 
is  rarely  accomplished  in  the  same  sequential 
manner,  making  it  ad  hoc.  The  iterative  nature 
makes  it  difficult  for  the  domains  to  work 
concurrently,  since  there  is  tight  coupling 
between  the  two  domains. 

Complexity  associated  with  the  emergent 
behaviors  poses  a  similar  challenge  to  both 
domains.  The  physical  subsystems  of  the  warfare 
system,  for  example  the  welding  of  a  ship  hull, 
the  calibration  of  an  electronics  console,  or  the 
stability  of  a  hull  form,  can  be  tested  by 
straightforward  means.  The  automated  computer 
network  control  system  or  the  networked 
battlegroup  interconnectivity  emergent  behavior 
presents  a  challenge  since  the  complete  system 
exists  only  when  the  battlegroup  is  deployed  at 
sea. 

Until  recently,  the  method  of  “build  a  little,  test  a 
little,  learn  a  lot”  (Meyer)  expressed  the  fact  that 
characteristics  associated  with  complex 
interconnected  systems  had  to  be  established  by 
small  steps  of  educated  linear  extrapolation  from 
known  behaviors,  trial  and  error  testing,  and 
evaluation  of  results.  Each  step  had  to  be  large 
enough  to  be  significant,  but  intentionally  kept 
small  enough  to  manage  risk. 

Today,  engineers  must  be  even  more  concerned 
with  the  links  that  connect  systems,  rather  than 
just  the  systems  themselves.  Warfare  systems  are 
tested  using  actual  equipment  located  at  dispersed 
land  based  sites  in  conjunction  with  sea-based 
platforms.  For  example,  the  following  land-based 
test  sites  can  be  connected  to  evaluate 
functionality:  a  DD-963  in  Dam  Neck,  VA,  an 
Aegis  cruiser  in  Morristown,  NJ,  and  Aegis 
destroyer  in  Dahlgren,  VA,  a  CV  in  Ft.  Loma, 
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CA,  and  an  E-2C  in  Pt.  Magu,  CA.  These  systems 
are  connected  through  T-1  and  other  high  speed 
data  links  to  simulate  battlegroup  interoperability. 
These  sites  are  also  coimected  to  ships  at  sea  to 
expand  the  test  to  the  operational  environment.  A 
“D  minus  30”  process  is  implemented  to  start  the 
process  of  battlegroup  configuration  at  30  months 
prior  to  deployment.  During  the  30  months,  new 
system  components  are  installed  and  tested, 
configuration  controlled,  and  eventually  deployed 
with  confidence  that  the  overall  system  will  work. 
The  overall  engineering  process  is  one  of  system 
integration  where  elements  and  subsystems  are 
integrated  bit-by-bit  to  form  the  complete  warship 
system.  These  approaches  and  others  are  currently 
being  used  to  engineer  warfare  systems,  but  rapid 
technology  development  change  causes  great 
challenges  in  the  ability  to  keep  the  latest 
capability  deployed  over  the  entire  warfare 
system.  The  consideration  of  these  aspects  poses 
both  a  theoretical  and  a  practical  challenge. 

THE  THEORETICAL 
CHALLENGE 

The  theoretical  challenge  is  defining  the  warfare 
system  in  terms  of  functional  coherence,  since  all 
battlegroups  are  neither  identical  in  terms  of 
specific  elements  and  number  of  elements  nor  in 
the  temporal  make-up  of  the  force  during  the 
mission.  For  the  ship  system,  the  subsystems 
used  to  provide  connectivity  may  vary  from 
element-to-element  as  new  ones  are  introduced 
and  older  ones  retired.  For  the  temporal  aspeet, 
during  deployments  some  ships  may  be 
reassigned  causing  coimectivity  changes  and 
hence  changes  to  the  system  coherence. 

Until  an  actual  deployment  occurs,  the  warfare 
system  cannot  be  completely  defined  in  terms  of 
its  boundaries,  its  nodes,  or  the  interaction  of  its 
networked  components.  Complexity  theory  is  not 
mature  enough  to  be  applied  to  the  engineering  of 
system  emergent  behavior.  Until  complexity 
theory,  or  some  related  one,  applies  to  warfare 
system  engineering,  challenges  will  continue  to 
confront  engineers,  since  construction  of  full- 
scale  prototype  warships  and  interconnected 
battlegroups  for  the  purpose  of  evaluation  is  not 
practical. 


THE  PRACTICAL  CHALLENGE 

The  practical  challenge  is  to  define  a  design 
methodology  that  allows  both  naval  architects  and 
combat  system  engineers  to  perform  design  using 
a  method  that  formalizes  design  semantics  and 
maintains  the  decomposed  subsystem 
interconnections.  A  generalized  method  for 
implementing  design  that  allows  mapping  of 
function  to  form  while  eliminating,  or  at  least 
bounding,  iteration  would  assist  in  creating  an 
environment  for  the  domains  to  work 
independently  while  achieving  an  integrated 
system.  Determining  iterative  coupling  allows 
design  teams  to  work  independently,  with  the 
subsystem  couplings  defining  the  context  for 
cross  team  interactions  at  the  interfaces.  Such  a 
generalized  method  has  been  defined,  and  is 
proposed  as  a  framework  for  redefining  the 
process  of  engineering  warfare  systems.  The 
method  is  neutral,  and  does  not  advocate  a  need  to 
train  engineers  as  designers  in  all  areas,  but 
allows  domain  specific  engineering  with  due 
consideration  of  coupling  interfaces.  The  method 
is  based  on  the  axiomatic  approach  to  design 
(AAD)  (Suh  1990  and  2000). 

AXIOMATIC  APPROACH  TO 
DESIGN 

The  ultimate  goal  of  axiomatic  design  is  the 
formulation  of  scientific-based,  non-iterative 
design  solutions.  Pure  axiomatic  design  takes 
place  in  a  “solution  neutral”  environment.  It  is 
often  difficult  for  the  designer  to  remain 
completely  “solution  neutral”  because  all  existing 
design  solutions  must  necessarily  be  disregarded. 
The  goal  is  to  explore  the  feasibility  of  using 
axiomatic  design  principles  to  define  an  efficient 
way  to  structure  the  system  design  process.  The 
foundation  of  axiomatic  design  is  two  axioms:  the 
Independence  Axiom  and  the  Information  Axiom. 
The  Information  Axiom  is  neither  discussed,  nor 
utilized  in  this  paper. 

The  axiomatic  approach  to  design  decomposes  the 
process  into  four  separate  domains,  the  customer 
domain,  the  functional  domain,  the  physical 
domain,  and  the  process  domain.  A  specified 


9 


vector  type  characterizes  each  domain  as  shown 
in  Figure  8.  Mapping  enables  the  designer  to 
logically  progress  through  the  design  process  by 
first  determining  what  is  required  in  each  domain, 
and  then  specifying  how  these  requirements  are 
satisfied  in  the  next  successive  domain.  Mapping 
between  the  domains  is  done  using  design 
matrices.  The  entire  process  advances  by 
“zigzagging”  between  adjacent  domains,  thereby 
producing  a  hierarchical  decomposition  as  the 
design  is  defined  in  increasing  detail. 

The  axiomatic  design  principles  have  previously 
been  outlined  as  a  naval  ship  design  process 
framework  (Brown  and  Thomas  1998).  The 
domains  are  tailored  to  reflect  concept  level  ship 
design  with  the  customer  domain  referred  to  as 
the  mission  domain.  This  fi-amework  provides  the 
basis  for  both  naval  architects  and  combat  system 
engineers  to  define  a  single  design  process. 
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When  viewing  the  design  process  in  this  mission 
driven  context,  the  customer  domain  may  also  be 
called  the  mission  domain.  Once  the  mission 
requirements  are  clearly  defined,  an  analysis  of 
alternatives  (AO A)  determines  the  best  means  of 
performing  the  mission.  Therefore,  the  MNS  is 
the  primary  means  to  determine  the  customer 
attributes  (CAs)  requiring  mapping  into  the 
functional  domain.  In  turn,  the  CAs  determine 
the  functional  requirements  (FRs)  and  the  overall 
constraints  placed  on  the  design  process. 
Constraints  limit  the  designer’s  available  choices 
of  design  parameters  (DPs).  Figure  9  illustrates 
the  progression  from  initial  exploratory  mission 
analysis  to  conceptual  physical  design. 


The  current  practice  used  to  evaluate  the 
effectiveness  of  a  naval  combatant  is  based  on  its 
ability  to  carry  out  the  specific  missions  it  was 


Figure  8.  Design  Domains  including  Characteristic 
Vectors 

The  Role  of  the  Customer  Domain  and  the 
Process  Domain 

The  formulation  of  specific  customer 
requirements  begins  with  the  exploratory  mission 
analysis  process.  The  key  result  of  such  an 
exploration  is  a  detailed  Mission  Needs  Statement 
(MNS)  which  outlines  all  facets  of  the  mission 
that  must  be  accomplished.  The  accomplishment 
of  the  stated  mission  is  the  reason  for  beginning 
the  conceptual  design  process.  Both  naval 
architects  and  combat  system  engineers  should  be 
designing  to  the  MNS. 


Figure  9.  Mission  Driven  Design  Progression 

designed  to  accomplish  according  to  the  MNS. 
Therefore,  effectiveness  is  measured  in  a  context 
where  the  ship  itself  is  viewed  as  a  component, 
for  instance  during  carrier  battlegroup  or 
amphibious  operations,  of  a  system.  Typically, 
trade-off  studies  are  conducted  to  determine  the 
optimum  combination  of  physical  attributes 
(weapons  payload,  propulsion  plant  type,  storage 
capacity,  etc.).  These  studies  solidify  the 
customer  attributes. 

In  the  axiomatic  approach  to  design  framework, 
effectiveness  of  a  design  is  based  on  its  ability  to 
satisfy  the  specified  functional  requirements. 
Once  the  best  conceptual  design  is  determined  in 
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the  system  framework,  the  customer  attributes  are 
mapped  into  the  functional  domain.  Upon 
entering  the  functional  domain,  axiomatic  design 
is  the  method  used  to  ensure  maximum  mission 
effectiveness. 

Formal  mapping  from  the  customer  domain  into 
the  functional  domain  is  challenging  for  naval 
systems.  Formal  mapping  of  CAs  into  FRs  is 
often  difficult  because  the  customer  is  often 
unable  to  precisely  outline  the  desired 
specifications.  For  this  reason,  after  a  physical 
conceptual  design  materializes  it  must  be 
presented  to  the  customer.  If  the  proposed  design 
does  not  meet  the  expected  performance,  the  CAs 
are  modified  causing  the  design  goals  to  be  re¬ 
defined.  Figure  9  also  illustrates  this 
phenomenon. 

By  use  of  a  design  matrix,  design  parameters 
(DPs)  in  the  physical  domain  are  fulfilled  by 
process  variables  (PVs)  in  the  process  domain. 
Process  variables  are  the  production  and 
manufacturing  resources  needed  to  physically 
construct  the  required  design  parameters.  In  the 
context  of  ship  design,  the  production  tools  and 
techniques  used  to  construct  each  portion  of  the 
ship  comprise  the  possible  PVs. 

Mapping  from  the  Functional  Domain  to 
the  Physical  Domain  and  Design 
Decomposition 

Considering  the  functional  domain  as  including 
both  naval  architecture  and  combat  systems 
functions,  the  AAD  integrates  the  design  process. 
The  design  questions  become,  “what  functional 
requirements  (FRs)  must  be  provided”  and  “how 
is  each  specified  requirement  fulfilled  by  use  of 
design  parameters  (DPs).”  Equation  1  expresses 
the  design  process  in  vector  format.  Equation  2 
represents  the  individual  equations  comprising  the 
design  process.  The  entire  analysis  is 
accomplished  by  “zigzagging”  between  these  two 
domains,  as  the  design  is  refined  through 
decomposition. 


=  (1) 
{FJ?}  =  functional  requirement  vector 
{dp}  =  design  parameter  vector 
[a]  =  design  matrix 

FRi  =  '£AijDPj  (2) 

J 

When  following  standard  practice  to  initially 
evaluate  a  design,  ^s  and  O’s  populate  all  design 
matrix  elements  Ay.  These  symbols  represent  the 
interaction  between  FRs  and  DPs.  An  X  in 
position  ij  signifies  DPj  effects  FR,.  Similarly,  an 
O  in  position  ij  signifies  DPj  does  not  effect  FF,. 
Equation  3  provides  the  mathematical  definition 
of  the  design  matrix  elements. 

Aij  =  dFRi/dDPj  (3) 

If  DPj  never  changes  in  such  a  way  as  to  influence 
FRi,  Ay  is  represented  by  an  O.  Ay  may  be  either 
constant  or  varying  throughout  the  design  space. 
If  Ay  is  not  a  constant  value,  it  must  be  evaluated 
at  specific  design  points  in  the  physical  domain. 
Additionally,  FF,-  does  not  always  vary  linearly 
with  DPj.  In  these  cases,  as  DFy  changes,  the 
value  of  FF,  either  increases  or  decreases  in  a 
nonlinear  manner.  Therefore,  varies  with  both 
FF,andDPy. 

Equation  4  shows  an  arbitrary  functional  to 
physical  domain  mapping  applying  these 
definitions.  Equations  5  list  these  sample  design 
equations  in  simultaneous  equation  format  for 
further  clarification.  Note  that  all  X  s  are  replaced 
by  their  respective  matrix  element  designation  in 
the  simultaneous  equations.  For  detailed  analysis, 
the  initial  design  equations  characterized  by  A’s 
and  O’s  are  updated  at  the  appropriate  level  of 
decomposition  by  replacing  each  X  with  a 
quantifiable  engineering  expression. 
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FRx 

X  0  X  ...  o' 

DPx 

to 

X  X  0  ...  0 

DP2 

FR3 

>  = 

X  X  X  ...  0 

DP3  > 

FRi 

X  X  X  ...  X 

DPj 

FR\  =  AxiDPi  +  AnDP3^...  (5) 

FRi  =  AixDPx  +  A22DP2  +  ... 

FRz  =  A3xDPx  +  A32DP2  +  A33DP3  + ... 

FRi  =  AixDPx  +  AnDP2  +  Ai3DP3  + ...  +  AijDPj 

The  “zigzagging”  process  enables  the  designer  to 
logically  decompose  the  design,  thereby 
developing  FR  and  DP  hierarchies.  Figure  10 
illustrates  this  process.  First,  the  designer  selects 
a  DP  to  satisfy  a  particular  FR.  Then  a 
determination  regarding  further  decomposition  is 
made.  If  the  selected  DP  is  a  well-established 
component  or  system  that  does  not  require  re¬ 
design,  the  decomposition  stops.  For  example,  a 
naval  architect  seldom  designs  the  prime  mover 
that  propels  the  ship.  Instead,  the  appropriate 
engine  is  selected  from  an  existing  marine 
propulsion  database.  In  this  case,  decomposition 
ceases  once  the  naval  architect  selects  the  desired 
engine  type. 

On  the  other  hand,  if  the  chosen  DP  is  not  a  well 
understood  legacy  component  or  system, 
decomposition  is  required.  The  designer 
decomposes  the  DP  by  determining  the  FRs  it 
fulfills.  Then,  each  of  these  FRs  is  satisfied  with 
a  suitable  DP.  Once  again,  a  determination 
regarding  the  status  of  the  lower  level  DP 
decomposition  is  made  using  the  stated  criteria. 
The  designer  “zigzags”  between  the  two  domains 
in  this  fashion  until  all  the  lowest  level  DPs  do 
not  require  re-design.  This  lowest  lower  of 
decomposition  is  referred  to  as  the  leaf  level.  The 
DPs  at  this  level  are  called  leaf  nodes. 


Functional  Domain 

Physical  Domain 

Figure  10.  “Zigzagging”  between  Domains 


The  standard  practice  of  tracking  the  design 
hierarchy  is  to  use  a  numerical  accounting 
scheme.  Each  highest  level,  or  parent,  FR/DP 
pair  is  given  a  sequentially  increasing  number 
designation  (1,  2,  3, ...).  At  the  next  level  of 
decomposition,  the  first  child  level,  a  sequentially 
increasing  number  is  added  to  the  right  of  the 
parent  designation.  For  this  paper,  a  decimal 
point  separates  these  two  fields  (for  example,  1.1, 
1.2,  1.3, ...  or  2.1,  2.2,  2.3, ...).  If  further 
decomposition  is  necessary,  this  procedure  is 
again  followed  and  a  sequentially  increasing 
number  is  added  to  the  right  of  another  decimal 
point  (for  example,  1.1.1,  1.1.2,  1.1.3,...).  In  this 
manner,  the  design  grows  as  branches  until 
reaching  the  leaf  level.  The  detail  of  each  branch, 
that  is  the  level  of  decomposition,  varies 
depending  on  the  DPs  selected. 

A  good  design  maintains  the  independence  of  the 
functional  requirements  according  to  the 
Independence  Axiom.  According  to  axiomatic 
design  theory,  the  design  process  does  not 
continue  to  the  next  level  of  decomposition  until 
the  Independence  Axiom  is  satisfied.  It  is  this 
independence  that  allows  subsystem  to  continue 
their  designs  in  their  own  discipline,  since 
interfaces  have  been  accounted  for  in  the 
decomposition.  Independence  is  achieved  by 
either  an  uncoupled  or  decoupled  design.  An 
uncoupled  design  is  one  in  which  only  one  DP 
satisfies  each  FR.  A  diagonal  design  matrix 
characterizes  this  type  of  design.  A  decoupled 
design  is  one  in  which  the  independence  of 
functional  requirements  is  satisfied  if  and  only  if 
the  DPs  are  changed  in  the  proper  sequence.  A 
triangular  (upper  or  lower)  design  matrix 
characterizes  this  type  of  design. 
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A  coupled  design  does  not  satisfy  the 
Independence  Axiom.  This  type  of  design 
signifies  the  need  for  iteration  because  successive 
DPs  are  not  necessarily  fixed  as  FRs  are 
sequentially  satisfied.  In  other  words,  a  DP  may 
require  modification  to  satisfy  one  or  more 
additional  FRs.  Once  this  modification  occurs, 
the  fulfillment  of  the  original  FR  (in  part  by  the 
subject  DP)  must  again  be  verified.  If  fulfillment 
is  not  achieved  the  subject  DP  must  once  again  be 
altered  initiating  the  iteration  process.  A  design 
matrix  with  elements  populating  both  sides  of  the 
diagonal  characterizes  a  coupled  design. 

Certain  functional  requirements  of  ships  are 
inherently  coupled  (i.e.,  operate  on  surface  of  the 
water  and  move  through  the  water).  Therefore, 
developing  a  decoupled  design  is  sought.  A 
decoupled  design  allows  the  designer  to 
concentrate  all  efforts  in  a  logical  sequence 
thereby  eliminating  the  iteration  process  and 
allowing  independent  design.  Once  a  portion  of 
the  design  is  complete,  it  theoretically  does  not 
require  further  modification  upon  completion  of 
another  aspect  of  the  design. 

The  benefits  of  achieving  a  decoupled  design  are 
seen  not  only  during  the  design  process,  but  even 
after  the  design  is  complete.  Technologies  to 
improve  the  warfighting  capabilities  of  modem 
naval  surface  combatants  are  continuously  under 
development.  This  is  especially  tme  for 
applications  involving  computer  microprocessing 
technology.  Therefore,  it  is  often  desirable  to 
install  these  new  technologies  onto  the  ship  once 
they  are  fully  developed.  This  can  happen  at  any 
conceivable  point  throughout  the  ship's  life  cycle. 
A  decoupled  design  allows  the  overall  effect  these 
new  teclmologies  have  on  other  systems  to  be 
determined  prior  to  insertion.  Therefore, 
modifications  enhancing  the  ship  are  less  costly  to 
implement  at  any  stage  of  its  operational  life, 
including  the  ability  to  integrate  new 
interoperability  functions  as  new  battlegroup 
configurations  are  required. 

CONCLUSIONS 

The  battlegroup  is  a  military  force  consisting  of 
ships  and  other  elements  interconnected  by 


automated  communication  links,  both  within  the 
ship  and  beyond,  to  create  warfare  system.  A 
further  complication  is  that  links  are  established 
when  the  force  deploys  which  means  that  the 
warfare  system  is  integrated  as  a  consequence  of 
its  existence  and  not  as  the  end  product  of  a 
constmction  process.  The  ability  to  design 
warfare  systems  for  desired  emergent  behavior 
remains  a  challenge. 

A  warship  is  the  result  of  a  protracted  and 
complex  design  and  integration  process  that 
requires  getting  it  right  the  first  time.  The 
warship  can  be  built  to  a  set  of  specifications  that 
accomplishes  physical  integration,  but  the 
functional  requirement  hierarchy  requires 
integrated  consideration  a  priori.  Building  a 
prototype  to  test  the  engineering  approach  is  not 
practical  for  large  systems,  so  the  Navy  has 
established  an  alternative  approach  that  relies  on 
test  and  evaluation  as  a  routine  part  of  system 
integration.  The  construction  of  large  complex 
systems  is  really  an  application  of  a  process  of 
defining  independent  fimctions  and  mapping  them 
to  physical  design  parameters  to  come  up  with 
design  specifications. 

Following  present  ship  design  methods  using  the 
two  domains  of  naval  architecture  and  combat 
systems,  the  modem  warship  is  defined  by 
multitudes  of  physical  attributes.  In  order  to 
achieve  a  design  solution,  many  of  these 
parameters  must  be  designed  multiple  times,  and 
ultimately  compromised,  using  an  iteration 
process.  Using  the  axiomatic  approach  to  design, 
these  multitudes  of  physical  attributes  are  reduced 
to  small  sets  of  functional  requirements  of  the 
highest  type  simultaneously  spanning  both 
domains.  These  functional  requirements  are  then 
satisfied  by  physical  design  parameters  through  a 
logical  mapping  process  from  the  functional 
domain  into  the  physical  domain.  Further 
decomposition  of  the  FRs  and  their  corresponding 
DPs,  in  tandem  with  “zigzagging”  back  and  forth 
between  the  two  domains  creates  a  highly 
ordered,  scientifically  arrived  at  design  solution. 
This  concept  solution-neutral  approach  allows 
designers  to  develop  new  and  possibly  innovative 
solutions  to  meet  FRs  in  a  cost-effective  manner. 
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